A central processing unit (CPU), or simply “a processor,” is a hardware component of a computer system responsible for carrying out the instructions of a computer program. Two types of processors are ARM processors and x86 processors. ARM processors have a relatively simple architecture which makes them suitable for low power applications. As a result, ARM processors have become the dominant processor in the mobile and embedded electronics market. The term x86 refers to a family of instruction set architectures based on the Intel 8086 CPU. X86 processors are more suitable for higher power environments and are widely used in modern PCs.
A distinction between ARM processors and x86 processors is that x86 processors possess a system management mode (SMM) while ARM processors do not. The SMM is a special operating mode that is reserved for firmware. The SMM is used by firmware to perform certain functions is a secure manner without the possibility of interference by the operating system or an application.
There are a variety of ways in which applications may interact with or engage the services of the firmware while an operating system is running. One way involves the use of legacy x86 real-mode interfaces. Legacy x86 real-mode interfaces were introduced with the IBM PC in 1980 and use the x86 software interrupt instruction (INT) to force the CPU to jump to a pre-defined address which identifies an entry point into the firmware. Parameters may be passed between the application and the firmware using CPU registers or buffers. Unfortunately, legacy x86 real mode interfaces do not exist on non-x86 (e.g., ARM) platforms. Further, legacy x86 real-mode interfaces are not supported on some x86 firmware implementations, such as pure UEFI. Legacy x86 real-mode interfaces also have the limitation that memory above 1 MB cannot be accessed.
Another way for applications to interact with or engage the services of the firmware is through an implementation of the UEFI specification. The UEFI specification defines a class of drivers called ‘runtime’ which indicates that the drivers (and the services they provide) persist while the operating system is running. In addition, UEFI itself provides a runtime services table which exposes services and data provided by the system firmware. The EFI system configuration table is an extensible, searchable data structure pointed to by this table and which is often used to provide the address of runtime services to OS applications and drivers. However, UEFI interfaces cannot be supported on non-UEFI firmware or with non-UEFI operating systems (e.g., DOS, WinXP, and some Linux distributions). UEFI runtime also does not provide memory management, synchronization, or service discovery facilities.
Applications may also interact with or engage the services of the firmware via a System Management Interrupt (SMI). On many x86 platforms, write operations directed to specific I/O ports or memory-mapped I/O locations will generate a SMI. On detection of the SMI, all CPU cores switch into System Management Mode (SMM) and begin execution at a pre-defined address. The actual value written to the port is typically used as a function code that specifies the type of system firmware service to be invoked. Additional parameters may be passed in CPU registers, other ports, or through a memory buffer. However, SMI and SMM do not exist on ARM platforms. SMM cannot be provided by ARM platforms without additional hardware support from the chipset or the CPU.
Another way in which applications may interact with or engage the services of the firmware involves an implementation of the ACPI specification. The ACPI specification describes a pseudo-machine language (AML) which may be interpreted by many operating systems to provide additional functionality. AML is provided by the system firmware. However, AML has limited access to the hardware. In general, AML only has access to the hardware resources that have been exposed to the operating system. Many implementations also have performance problems.
Applications may also interact with or engage the services of the firmware using a customized operating system (OS) driver. In the customized OS driver approach, rather than using the firmware at all, each OS driver is specifically crafted for each supported operating system so that the customized OS driver contains the necessary functionality for that operating system. Naturally, this approach requires a separate implementation for each operating system and each hardware platform, which is quite time consuming and costly. Further, such customized OS drivers would not have access to firmware configuration data, such as setup options.
Use of a proprietary OS driver/firmware interface may also be used to allow an application to interact with or engage the services of the firmware. Using a proprietary OS driver/firmware interface is similar to using a customized OS driver, except that the firmware service discovery, invocation, parameter passing, and environment are proprietary. The entry point for the services provided by the firmware may be hard-coded, found by looking for a pre-defined signature, or passed via some custom discoverable table. This approach has the disadvantage of being more difficult to understand and transfer to new engineers. In addition, it is more difficult to adapt other third party firmware code to use a proprietary OS driver/firmware interface.
Discussion in this section is meant to provide an understanding of prior approaches to the reader as they relate to embodiments of the invention. However, the disadvantages of prior approaches discussed in this section are not meant to be an admission that such disadvantages were publically known. Consequently, recognition of the disadvantages of the prior art discussed herein is not meant to be construed as being within the prior art simply by virtue of its inclusion in this section alone.